The Data Model

The SOS data model provides mechanisms for defining types. These are defined in modules that are called schemas. The notation for these type definitions within a schema is described in Section [*].

Enumeration types are used to specify finite sets of constants by listing the elements. External types are used to manage the link to types of some programming language. Enumeration types and external types are called scalar types; they are the primitives from which classes and unions may be constructed as will be described subsequently. The set of objects whose type is a scalar type are (conceptually) created together with the type definition; no objects of a scalar type can be explicitly created.

The central notion in SOS is the notion of a class. Each class is declared by the structural and behavioral properties common to its instances. The structural properties are declared by components (slots, or attributes, as they are called in other languages); the behavioral properties are declared by methods (operations, functions). Class types provide information hiding capabilities by dividing the methods into private, protected and public ones. Public methods define the interface to the instances of the class, whereas private and protected methods may be invoked only by the implementation of the methods of the class itself, or its derived classes, respectively. Besides its state which is made up from its components every instance has a unique system generated identifier that is representing its identity. It can be used as a reference to this instance.

The components of an object may not only be objects of scalar types (i.e. values) but also objects or references to objects of the same or a different class. Those components may be defined by value or by reference. The difference between the two notions lies on the operational part of the data model which is made up of the methods declared for each class, respectively. Components of an object which are defined by value, so-called value components, are considered to be a dependent part of the object that cannot further exist after the destruction of the object. An object can only be a value component of one other object. If such a connection between two objects is established once, it can not be loosened any more. Consequently, it is not possible to perform an explicit destroy operation on a value component. Objects, which are instances of classes, are explicitly created. It is intended that value components are created together with the creation and destroyed together with the destruction of their master object.

Two objects are identical when they have the same identity; two objects are equal if all of their non-value components are identical, and their value components are equal. That means, that the equality check is recursively applied to each of the value components.

Class inheritance is a mechanism for factoring out common properties of classes in parent classes. New classes that inherit properties from existing classes are called derived classes. The SOS data model supports multiple inheritance, which means inheritance of a subclass from several parents; name clashes are explicitly precluded. The "inherits from" relationship defines a partial order on a set of classes. All classes have a common parent class called sos_Object. As a consequence, the type hierarchy may be visualized by a directed acyclic graph with a single root node.

Another way of generalization is the definition of generic classes which are parameterized with type parameters. The instantiation of a generic class generates the declaration of a specific class by substituting actual types for the formal type parameters in the according methods. Arbitrary new type constructors, for instance Set<T> or List<T>, may be defined as generic classes. The result of an instantiation may then be a type like Set<List <int>>.

Union types may also be used to generalize types in a way, such that an instance of one of the united types may appear where the union type is required. It is not possible to create instances of a union type and no methods are provided for them. Union types are just a means to declare generalized types after the more special classes. In contrast to that, when using the type hierarchy to describe generalization, superclasses must be introduced before the more specialized classes.